Consider the example of TributeCoin. The minting policy for TributeCoin says that anyone can forge it so long as they send me (Michael Peyton Jones) X Ada for each coin that they mint.

Now, if I understand this scheme correctly, any person who mints TributeCoin could also include transaction metadata indicating that their keys should be associated with the asset id. This could lead to them squatting on the metadata, or it might lead to multiple registrations if the true owner (or other bystanders!) submitted more registrations.

So at the least I think this CIP needs a proposal for what to do in case of multiple registrations. A simple solution would be to privilege the first such registration; but this then introduces incentives for front-running such transactions in order to squat metadata.

The underlying issue is that it is just not true that the party who mints the tokens is also the party who "owns" the tokens (in the social sense of: wrote the script, runs the scheme, agrees to exchange them for things, etc.). So the fact that a transaction mints tokens is not proof that that person has the right to make metadata associations.

Well, to a certain extend, if you are able to mint asset A, you effectively are the owner of asset A and being able to set metadata for that asset sounds reasonable. You minted it after all.

Yet, there's an issue w.r.t to keys associated with the policy itself, for which I agree, ownership is generally ambiguous / undefined.

Well, to a certain extend, if you are able to mint asset A, you effectively are the owner of asset A and being able to set metadata for that asset sounds reasonable. You minted it after all.

I don't agree with this at all. You own the token in the sense that you can move it around on the chain, but I think it's a serious confusion to mix that up with the person who should be setting the metadata. Let's call the two parties "the owner" and "the organizer".

Perhaps it would help if I gave a more realistic example. Suppose Alice (the organizer) wants to run an auction. She sets it up so that in order to participate, you have to lock up some collateral at a particular script address, and this lets you (the owner) mint a participation token. All the participation tokens have the same asset id (i.e. are fungible). You can then use the token to register a bid, and at the end Alice completes the auction, taking a fee from the locked funds of each participant, and the entirety if they failed to participate. (Bit of a weird auction, but never mind)

Who should set the metadata for the token? Is it Alice who actually set up the whole thing? Or is it Bob, Carol, Dave, Edna ... who minted participation tokens? I think that any answer other than Alice is clearly wrong, and a system which makes it possible (let alone easy) for Bob, Carol, Dave etc. to do so (or to effectively contest it) is wrong-headed and will dissuade people from running such (sensible) setups because of how easy to abuse they would be.

Yet, there's an issue w.r.t to keys associated with the policy itself, for which I agree, ownership is generally ambiguous / undefined.

No, because people will also mint fungible tokens multiple times. Asset ids absolutely can appear in multiple minting events.

Ultimately, I think this scheme mostly works for NFT drops. I wouldn't object to that if it weren't for the fact that it seems actively harmful for other setups. And we have no way of distinguishing an NFT-drop-like scenario from any others (it's... metadata!), so I'm not sure how we could even limit it to that case.

I see your point; I still think there's a good bunch of use-cases which can be covered by this approach nonetheless. Perhaps it needs to be "branded" better even though I don't think the proposal currently claims to solve the ownership question by itself. It merely gives one way of linking some keys to some policy, which may turn useful for some use-cases where the minters are also the token metadata owners (and I insist that so far, this has been the most common case).

What do you think of adding a warning / disclaimer that, this particular solution only work under this particular assumption but is probably unfit for other use-cases?

What do you think of adding a warning / disclaimer that, this particular solution only work under this particular assumption but is probably unfit for other use-cases?

So how do I, as the consumer of token metadata, know whether this is a usecase where the metadata can be trusted, or one where it can't?

The issue isn't that it works in one case and can't be used in another case, it's that it in the cases where it doesn't work it's an attack vector, and there's no way for the consumer to distinguish those without... metadata. At which point you have to have established an alternative metadata channel which you might as well use for the rest of it.

It merely gives one way of linking some keys to some policy

But the meaning of that link is unclear without metadata. It could tell you that the link was created by the "organizers", and thus you can trust it. Or it might not. And you can't tell which.

Ultimately, the decision to trust a key belongs to the end users. Only the discovery of keys is automated through that CIP. Yet, yes, I agree that it's potentially confusing and could be used in an adversarial way.

Hmm. I originally thought of this as a way for token issuers to leverage the chain to advertise their key. But, it is quite clear now that for this to work, it would be necessary to also clearly communicate that a token is following this CIP; in which case issuers could as well just advertise their public metadata keys.

This is quite unsatisfactory 😔. Alternatively, I imagine we could use a well-defined Plutus policy which would enforce that a token in only minted under some conditions which would render this approach valid. Given that the script hash is known of clients, it would solve the problem.

Only the discovery of keys is automated through that CIP.

Right, but the issue is that "discovery" has to mean something more than "here's a key", it has to say something about that key. A keyserver associates an email address with a key, etc. If we can't make any guarantees about this key... it's not very useful.

Alternatively, I imagine we could use a well-defined Plutus policy which would enforce that a token in only minted under some conditions which would render this approach valid.

All that Plutus scripts do is look at the transaction and check conditions... which is something that the client can perfectly well do themselves! And the thing that you really want to know (what is the minting policy saying?) is something that's opaque to everyone, and Plutus scripts have no privileged access to that.

Having said that, this could work for currencies whose policy is a "native" script, in much the same spirit as what you propose in the off-chain metadata proposal. Of course, that's much less interesting because you can just look at the policy itself, rather than putting something in the metadata and then looking at the policy to check that it's correct...

All that Plutus scripts do is look at the transaction and check conditions... which is something that the client can perfectly well do themselves!

What I meant is that, you can capture as a Plutus monetary policy the use-case where minter = owner in such a way that the monetary policy is recognizable by clients. That is, if a token is minted according to this particular policy, then CIP-XXXX applies. We can't do this with phase-1 monetary policy because the policy contains the key necessary for minting. With Plutus, you could imagine a policy that leverage the redeemer to define the minter, while keeping the policy itself static.

By fixing the policy, we have more freedom as how to define metadata for this type of policy (but it's also quite limiting since all assets minted under that policy need to share some common behavior). Also, take this with a grain of salt, it's mostly me grooming out loud without any clear design in mind.

What I meant is that, you can capture as a Plutus monetary policy the use-case where minter = owner in such a way that the monetary policy is recognizable by clients. That is, if a token is minted according to this particular policy, then CIP-XXXX applies.

I see. Yes, you could whitelist some monetary policies (configurable by the redeemer, as you point out), such that this CIP would apply. But then you would need to restrict it to metadata about the tokens forged there, since this policy would be shared between all parties making use of this scheme.